fix: wiki multi-level headings, tag hierarchy scope, and baseline advance#178
Open
bk-ty wants to merge 1 commit intokenforthewin:mainfrom
Open
fix: wiki multi-level headings, tag hierarchy scope, and baseline advance#178bk-ty wants to merge 1 commit intokenforthewin:mainfrom
bk-ty wants to merge 1 commit intokenforthewin:mainfrom
Conversation
…ance Three related fixes to wiki generation and the update proposal flow: Multi-level heading support (section_ops.rs, wiki/mod.rs): - Parser now recognises h3+ headings as addressable sections instead of swallowing them into the nearest h2 body. heading and after_heading fields in ops can now reference any ## or deeper heading. - extract_current_headings returns (level, text) pairs; the prompt renders sub-headings with indentation so the LLM sees the hierarchy. - apply_section_ops switches to a soft-fail mode per op: if a single op references a hallucinated heading, the rest still apply and the bad op is reported in the returned error list rather than aborting the whole update. - Prompt wording updated: '## headings' -> 'section headings' to avoid confusing models that generate h3+ content. Tag hierarchy scope (sqlite/wiki.rs, postgres/wiki.rs): - get_new_atoms_since and atom_count queries now use a recursive CTE to span the full tag descendant tree, matching the scope used by generation and get_article_status. Previously these queries only looked at atoms directly tagged with the exact tag_id, causing the 'N new atoms' banner to miscount atoms in child tags and fire spuriously. Advance baseline on no-op updates (lib.rs, storage/traits.rs, storage/mod.rs, sqlite/wiki.rs, postgres/wiki.rs): - When generate_wiki_update finds no changes worth proposing, it now calls advance_wiki_baseline to bump atom_count and updated_at to current values. This clears the 'N new atoms' banner and prevents the same atoms from being re-evaluated on every subsequent 'Generate Update' click. - accept_wiki_proposal: use proposal.created_at instead of a fresh Utc::now() for updated_at so the stored timestamp matches the proposal's age rather than the accept time.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Three related fixes to wiki generation and the update proposal flow.
1. Multi-level heading support
Problem: The section parser only recognised
##headings;###and deeper headings were swallowed into the nearest h2 body, making them invisible to ops likeAppendToSectionandReplaceSection. The LLM-facing heading list also showed a flat## fooprefix, obscuring document hierarchy.Fix (
section_ops.rs,wiki/mod.rs):##+ heading as a section boundaryextract_current_headingsreturns(level, text)pairs; the prompt renders sub-headings with indentation so the LLM can see the hierarchyapply_section_opsswitches to soft-fail: a bad op (hallucinated heading) is skipped and reported rather than aborting the entire updateTests updated and extended (25 tests, all pass).
2. Tag hierarchy scope for wiki queries
Problem:
get_new_atoms_sinceand theatom_countused inupdate_wikionly queried atoms directly tagged with the exacttag_id.get_article_status(which drives the "N new atoms" banner) uses a recursive CTE to count across the full descendant tree. The mismatch caused spurious banners for atoms in child tags that the update logic never actually passed to the LLM.Fix (
sqlite/wiki.rs,postgres/wiki.rs): Both queries now use the same recursive descendant CTE asget_article_status, so counts are always consistent.3. Advance baseline when no update is warranted
Problem: When
generate_wiki_updateran but the LLM found nothing worth changing, the article'satom_countandupdated_atwere not updated. Every subsequent "Generate Update" click re-evaluated the same atoms, and the "N new atoms" banner never cleared.Fix (
lib.rs,storage/traits.rs,storage/mod.rs,sqlite/wiki.rs,postgres/wiki.rs):advance_wiki_baselinestorage method bumpsatom_countandupdated_atwithout changing article contentgenerate_wiki_updatewhen no proposal is createdaccept_wiki_proposalnow usesproposal.created_atinstead of a freshUtc::now()forupdated_atTesting
cargo test -p atomic-core section_ops— 25/25 passcargo test -p atomic-core wiki— all pass includingtest_wiki_article_lifecyclecargo check -p atomic-core— clean